The emergence of cloud computing has resulted in the design and construction of large datacenters where multiple tenants are migrating complex applications that were once hosted in private enterprise networks. One of the most important enablers for this migration is system virtualization, which allows multiple servers, potentially belonging to different tenants, to be hosted on the same physical host. These servers, contained in virtual machines or VMs, can be transparently migrated between physical hosts without any noticeable disruption, providing a flexibility and elasticity to the cloud operators. In order to maximize this flexibility, an operator should be able to migrate a VM between different links in the data centers without being restricted by the topology of the interconnections.
Additionally, tenants typically would like to manage their own networks using their own addressing plans and ranges, thus easing the migration from their private datacenter into the cloud. Any network virtualization solution should provide isolation at the addressing level between different virtual networks while still maintaining the ability to forward traffic between the individual subnets belonging to the same tenant.
Most of the existing network virtualization solutions meet these requirements by creating overlays—either Layer 2 (L2) or Layer 3 (L3)—on top of a physical network. L2 solutions such as Shortest Path Bridge (SPB) and Transparent Interconnection of Lots of Links (Trill) encapsulate tenant traffic into outer L2 tunnels (a MAC header plus an additional header). L2 solutions are limited to a single L2 domain, although this domain can be quite large due to the use of a routing protocol between switches instead of relying on learning and flooding to populate forwarding tables. L3 solutions such as VxLAN and Network Virtualization using Generic Routing Encapsulation (NVGRE) use IP based tunnels. L3 solutions do not suffer from the scalability limitations associated with L2-based solutions but they do impose additional overhead because of the larger encapsulating headers.
Although the previously mentioned solutions allow the creation of per tenant isolated virtual networks, these networks are flat single L2 domains, i.e., one IP subnet. Such solutions do not address the need for tenants to subdivide their virtual network into different subnets and the problem of routing between different virtual subnets belonging to the same tenant.
Routing between different subnets in a virtualized network may be handled using a virtual-network router at a L3 gateway within the datacenter. This solution, however, requires significant routing capability at the L3 gateway—a conservative estimate is that four times the traffic flows through the router in this case. FIG. 1 illustrates communications between VMs using L3 gateway routing.
One sees a datacenter network 10 having L2 switches 12 and L3 routers 14 at the L3 gateway level. Servers 16 host any number of VMs, with VM1-VM4 illustrated by way of example. VM1 and VM4 operate in one subnet communication through respective ones of the L2 switches 12. The same is true for VM2 and VM3, which operate in another subnet. However, because communications between VM1 and VM3 involve different subnets, communications between VM1 and VM3 are routed through the L3 gateway via respective ones of the L3 routers 14.
FIG. 2 illustrates another known approach that involves designating certain VMs as software-based routers and default gateways for the virtual-network subnets to which they are attached. One sees a software router “R” implemented in one of the servers 16 according to such a configuration. While this approach lowers cost, it also introduces choke points in the network, because the traffic between subnets is limited by the link provided to a single VM.